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Abstract 


Designing a prograniiriiiig inoclol for distributed systems that is not too different from 
(.h(^ programming model for sequential systems is a highly desired and challenging 
task. Of the programming languages for sequential systems, object oriented languages 
lend themselves rather easily to distributed extensions. In this thesis, the design and 
implenunitation of a distributed object oriented programming environiuent(VASTU) 
is descrilKid. VAS'fU is based on the object oriented programming language C-f-+- 
Using the VASTU system, programmers can transparently create, access and destroy 
remote active objects. Active classes are sjjecified using the VASTU ADL(Active 
(!lass Desc.rii)(,ion Language). 'Fhe compiler for this language generates C++ code 
l.hat hides t,h(! details of distribution and provides a transparent interface to the clients. 
An object server runs on every machine in the system and is responsible for ci'eating 
objects on that machine. Access to active objects is controlled using capabilities. The 
VASTU system itself is used to imj)l(!ment a simple name server that can be used to 
nanui objects. 
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Chapter 1 


Introduction 


'I'hc' (i(^v(il(>i)nuiiit, of low cosl powerful inicroi)rocessors and high speed computer net- 
works ha.v(! r(!volutioni/(Hl the way computing is done. It was those two developments 
that. ciuis(!d the ndvxuit of distributed systems. A distributed system can be defined 
as a collection of computers or nricroprocessors interconnected by a communication 
n(!t,work, where? the? computers communicate with (?ach other through message passing 
and not. by sharing memory. The key difference between a distributed system and a 
iHitwork of c;omputers is the transparency provided by the distributed system. The 
syst.(?m hides the presence of multiple computers and provides a single system view 
to th(' user. 

Dist.ribut(!<l .syst(?ms have many advantage's to oiler ov(?r c:omputing with sc(iuential 
machiiu's. Tlu? first one is that programs can exploit the parallelism available due to 
multii)lf; CPUs. Tlu? second is higher reliability which couk's about due to the ability 
of the .system to tolerate partial failures. Another advantage is that such systems are 
w(!ll .suit<>d for incremental growth. 


1.1 Programming Models for Distributed Systems 

The duUlenge in distributed computing is to provide a model for programming which 
allows l.lu? programmer to achieve! tin? abov(! goals, yet it is not too different from the 
way s(!(nu!ntial machines are programmed. There are many ways in which this can 
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!>(' a(;hi(!V(’d. 


1.1.1 Parallelizing Compilers 

.Sonui c()m[)ilors, for example, [14, 21, 28] can extract parallelism from a sequential 
I)rogram and thus make it suitable for efficient execution on multiple CPUs. How- 
ev(>r, these are l)est at extracting fine grained parallelism which, due to the relatively 
larger (•.ommunicalion delays, is unsuitable for a collection of autonomous machines 
eoiiiKicted by a. communication network. Moreover, even tlui best of such compilers 
can (ixi.ract only a limit(xl amount of parallelism from the i)rogram. Also, using such 
a. mochd of programming, problems which are inherently distributed in nature can 
not be effectively modelled. This model is very efficient only when the parallelism is 
matlc^ explicitly visible to the programmer. 


1.1.2 Languages with Logically Shared Address Spaces 

In these languages, parallel units of a program have a logic.ally shared address space 
and (communicate through data stored in the shared addr(^ss space. Note that this 
d(j(cs not. mean that physical shar(^d memory is needed foi’ the im])lcmentation of such 
languag(cs. These; languages can be furtluu- chxssified into three categories. 

1 Functional languag(;s 

2 Logic; languages 

3 Distributed data structur(;s 


'!'!)(; implicit paralhclism in functional languag(;s is esp(;cially suit(;d for closely coupl(;d 
archit('cturos like data flow machines. But, they are unsuitable for distributed systems 
which are mostly coarse grained in general. However, there exist some languages like 
PaTAlJl[lb] which provide a mapping notation for efficiently distributing computation 
among multiph; proccissors. There exist paralkd logic languajjes like PARLOG[7] and 
languag(;K bas(;d on distribut(;d data structur(;s like Liv,da[H]. But, most of these 
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langiuif^c's aro d(\sigiiocl for multiprocessor machines with shared memory and would 
1)(^ relatively iiHiflicicut in a distributed environment. 

1.1.3 Languages with Distributed Address Spaces 

In tluise languages, the paralkd threads of computations within a program communi- 
ca.t,(^ by s(mding messages to each other. The address spaces of different computations 
do not ov(!rlap, so the address space of the whole program is distributed. 

'The most b;tsi(‘ model in this category is a group of seciuential processes running 
in j)arnllel and communicating through synchronous message passing. Example of a 
language, based on this model is Occam. Some languages use asynchronous message 
passing to increase the parallelism, i.e., the caller does not wait for the messages to 
1)(^ delivered but immediately continues to do other computation. 

Both of the abov(! models make the underlying hardware explicitly visible to the 
programmer and (,lia.t is what mak<w the life of the programmer, who is accustomed 
1,0 jjrogramming on uni-processor machines, difficult. What one would like to have is 
a mod(d which is as close as possible to the way sequential programming is done. Re- 
mote ProceduTC Call is a step in this direction. Using this mechanism, the interaction 
b(!tw(!(>n the two i)roccsses ai)pears as a normal procedure call to the programmer. 
This idea was first proposed by Birrell and Nelson in [r>]. There are several imple- 
tiKUil.atiouH of this idea su(;h fis Sim-H.PC[24], Apollo R.P()[2()] etc. 

()bj<'ct orient(xl languages lend themselves rather easily to distributed extensions. 
All one has to do is to think of objects as independent entities just like processes in 
1,h(‘ a.bove nuxhds. P(a‘forming an op(uation on an object can be visualised as sending 
a, nx'ssage to tlu; objcic.t. Parallelism can be achieved by making the objects active. 
That is, tiny just do not wait for nspic'Hts, tiny do sonu' op<'ration on their own 
also. More parallelism can be a(dii(wed by making the object multi-threaded and/or 
making use of asynchronous imd.hod invocations. 
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1.2 Object Oriented Programming 


Apinoiuiios to i)r()giaiiiining iiavc c.hangod (Irainatically siiico the invention of cornput- 
(MH. Inil.ially, pr()gra,mui(!is had to dir(ud,ly code in iiiac.hiiie language. Now, high level 
languages an^ available which inak(! prograinining easier. Paradigms of programming 
liav(! also changed considerably with the increasing complexity of programs. Initially, 
t,h(n(' was SlrucUtrad yrogmimimuj - the mochd encouraged by languages like C and 
Pascal. But, software maintenance became a ])roblom with this approach. Then came 
tli(' Objvr.i ()rir.nl.(\d which took the advantages of stnudairecl programming and 

r(!duc<’d th(> problem with software maintenance. This model simplified the task of 
I)rogramming since there is a close correspondence between the way a programmer 
visuali/,<'d the solution and the actual |)rogram. 


An object is an entity that encapsulates some private state information or data 
and a s('t of associated methods or i)rocedures that manipulate the data. The state 
of an object is completely protected and hidden from other objects. The only way it 
can be examined or modified is by the invocation of one of the associated methods. 
'Phis cr(^ates a well-defined interface for each object, enabling the specification of 
an obj(ui,’s operations to be made public while keeping the implementation of the 
op(!rations and the representation of the state private. 

A class is a template from which objects can be created. All objects that are 
creaUul using this teinj)late are said to be instances of the class. 


Inhe.ritancc is a mechanism by which new classes can use code of existing classes, 
simply by specifying how the new classes differ from the existing ones. In such a 
situaf.ion, tlui old class is calhul as l.lu^ base class or the super class and the new class 
is known as the derived class or the sub class and the relationship between them is 
(.(uined as an IS-A ndaXionship. The d('riv(^(l (dass gets all the functionality of its 
sn])er class. It can also add its own functionality or override some of the functionality 
of the super class. 


A programming language is termed as object oriented if it supports the notions of 
class(\s an< ,ance. By this delinitiou, languages such as C-f- 1-[22] and Smalltalk(l2] 
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a.r(' ohjc'ct oriented. An object oriented program has many objects which remain pas- 
sive and Hispond to method invocations whenever requested. There is only one thread 
of f;onl,rol at any given point of time. 


1.3 Distributed Object Oriented Programming 

A distril)ntod object oriented programming language provides the features of an object 
ori(!n(.(!d prograniming language as well jus supports a distributed (xmqmting environ- 
ment. A distributed object oriented program tyi)ically consists of many objects each 
of which may b(i ('-xecuting on a different machine and communicating with each other 
f.hrougli some communication protocol. In the following sections, we briefly look at 
SOUK! of t.he issues in supporting distributed object oriented prograrnmingfC]. 


1.3.1 Object Composition 


I’ln^ r(da,tionship between processes and objects characterises the composition of the 
obj(;(,:ts. There are two approaches to this. 

First, oru; is the Passive object model. In this model, processes and objects are 
completely separate entities. A process is not bound nor it is restricted to a single 
obj(!ct. 

Wlum a i)roc(!ss makes an invocation on another object., its execution in the current 
object is temporarily susi)ended. Concepttially, the process is then mapped into 
the addrciss space of the second object, where it excctitcs the appropriate operation. 
VVlum, it compkites this oi)eration, it is returned to the first object and it resumes the 
original operation. A typical scenario is depicted in Figure 1, where P is the process 
which invokes a method of object A. 


()bj(K;ts are passive entities here. They do not do anything on their own. They 
just resjjond 1,o nuJthod invocation re<iucsts. 


.Second model of object composition is the Active object model In this model, 
objects are, active (uitities. They do something on their own, in addition to servicing 
method invocation reepu^sts. When an object is created, many server processes(or 




Object A Object B Object C 


1: I’assivi' <)l)j('(;(, nuxh'l 

t.hrcads) aro ci(^a(,('.(l and assigned to the object. These processes die when the object 
is dcistroyed. 

Wluni a client makes an invocation, it forms a request message with the arguments 
and sends it to tin; obj(!ct. A s(!rv<!r process of the obj(!ct a.(u;epts this request and 
ptudbrnis the specified operation. Upon completion, it forms a reply message with 
the result of the operation and sends it back to the client object. A typical scenario 
is d(^pict,(!d in Figure 2, where PA, PB and PC are the server processes attached to 
tlu^ ()bj<!cts Object A, Object B and Object C respectively. 



Object A Object B Object C 

Figure 2: Active object model 


If (,h(i numlxu- of scu'ver proc<’sses is fixed, then the mochd is a a static variation 
of th<^ a.cf,ive object model. Here, requests that arrive when all servers are busy are 
(juciued and serviced lat(U-. If a servc'r process is (uea(.('d to handle (lach incoming 
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i('(|U('s(., tlio modol is a dynamic variation of the active object model. The addi- 
(.ioiial ()V(uhead in tonus of jjiocess creation and destruction can be minimised by 
maintaining a pool of idle processes. 


1.3.2 Locating the Object 

In a distributed environment, objects can reside on any machine. To invoke a method 
on an obj(!ct, the location of the object needs to be known. Therefore, there should 
1)0 ;i, way Ijy wliicli w(^ c.an get tlu' location of the ol)ject from tlie name of the object. 
Tluu'(^ ar(^ many schemes by which this can be achieved. 

One simple scheme is to encode the location of the object within its name. When- 
<'V('r an invocation is made, the location can be found out just by looking at the name 
of the object. This is the simplest and the most straightforward scheme. But the 
disadvantage is that it is not location and migration transparent. 

The second approach is to use a name server. There is an entity called name 
server running in the system at a well-known location. This maintains the mappings 
of local, ions and names of objects in the system. Objects can provide mappings to 
tlur naiiK! server and (;an get location of an object from the name server by giving 
t.lui name of the object. The drawback of this scheme is the centralised nature of the 
name server. The name server becomes a performance bottleneck as well as a critical 
point of failure. However, these problems can be addressed by replicating the name 
.server as in DCE[ 4 ]. 

A small cache can be maintained on each machine that records the last known 
lo(;ations of a number of recently referenced remote objects. When a client makes a 
remote Invocation, the cache can be examined to determine if it has an entry for the 
remot(i ol)ject. If a lo(;ation if found, the invocation is sent to that machine. If the 
location can not be found out from the cache, a message is broadcast throughout the 
network requesting the current location of the object. Every machine that receives 
the ixupiest does an internal search for the object. If it is found, a reply message is 
returned and the cache on that ma(;hine is updated upon receiving the reply. 
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Forward location pointers can be used to enhance most location schemes. A for- 
ward location pointer is a reference used to indicate the new location of an object 
which has moved from one machine to another. Whenever an object moves from one 
inachiiK^ to another, it leaves a forward location pointer at the original machine. To 
locat.ci an ol)je(-l, that has moved, the system can simply follow the chain of pointers, 
'riiis Hclnane can not completely handle the problem of finding migrating objects, 
siiHsi some pointers in the (;hain may be lost due to machine failures. 


1.3.3 Security 

Providing a security scheme to prevent unauthorized clients from succe.ssfully invoking 
met.hods of an object is an important issue in a distributed system. There are basically 
two approaches to solve this problem. 

dapalrdity scIkiuk! incorporates protection into the miming scheme. A capa- 
bilily works as an address for an object. It is also used to guarantee accesses. Upon 
creation of an object, clients get back a capability for the object. They have to use the 
capabilil.y for later method invocations on that object. Capabilities are transferable, 
resl.rict.able and unforgeablc. 

In the Control procedure scheme, every object has a control procedure through 
which all incoming invocation requests must first pass. This checks the authorization 
of clients making a reijuest and terminates all invalid requests. It is flexible, since it 
can support any type of security scheme. This permits each object to provide security 
tailored to the reciuirements of the object. If security is unimportant to an object, a 
minimal security scheme can be used. If an object is security sensitive, a more rigid 
scheme can be used. This scheme can also be used in addition to the capability based 
scheme. 


1.3.4 Object Scheduling 

()bjc(d, scheduling is (,he issue of choosing a processor in the system on which a new 
object shoifld be creatiid. This can In? either explicit or implicit. In an explicit sc'hedul- 
ing scluiUKli-Ue user is responsible for specifying the processor to which an object is 
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to be assigned. In the implicit scheme, the system is responsible for determining the 
location of the object. Typically, the system determines the load on the available 
machines and chooses the one with the lightest load. One drawback of this approach 
is that, getting accurate load information is very difficult and therefore, a machine 
which is observcKl to be lightly loaded may get assigned a number of objects and may 
b(H:ome overloaded by the time the object is created on that machine. 

1.3.5 Action Management 

Act, ion in a distributed ol)ject oriented system is a chain of related method invoca- 
tions, Since actions in a distributed object oriented system execute concurrently, the 
properties of an action should be maintained. The properties of an action are: 

• Serializability: Multiple concurrently executing actions should be scheduled in 
such a way that the overall effect is the same as if they were executed in some 
s(!rial order. 

• Atomicity: An action either successfully completes or has no effect. 

• Permanence: The effects of a successful action or not lost. 

To ensure these properties, protocols such as two-phase commit protocol [13] must be 
used. 


1.3.6 Synchronisation 

Another important function of a distributed object oriented programming system 
is to ensure that multiple actions that invoke the same object do not conflict or 
interfere with each other. Failure of this can lead to cascading aborts, i.e., an action 
that has observed the partially modified state of an object resulting from an action 
that later aborts, also has to be aborted. Two popular synchronisation schemes exist 
to avoid this. One takes appropriate steps to prevent conflicts from occurring. An 
action that invokes an object is temporarily suspended if it will interfere with another 
currently executing action. This scheme is called as pessimistic scheme. Another 



scIk'uk' (loos not, takos stops to provont conflicts from occurring. Instead, before an 
jictioii can commit, a check for seriali'/ability is done to ensure that the information 
it has observed is not out-of-date. This scheme is called a»s optimistic scheme. 


1.3. 7 Reliability 

'There? arc? two methods to provide gbject reliabilty. One is to recover a failed object 
as ([uickly as possible, limiting the amount of time for which it remains unavailable. 
Anol.her is to replicate objects at multiple machines so that even if one of them fails, 
th(' otlu'r can continue to service recjuests. 

1.3.8 Invocation Failures 

An invocation ca,n fail bec.aus(> of many n^asons. It can be because of a client failure or 
a serv(?r failure or a network failure. There are many failure detection algorithms[18] 
using tim(?outs and object probes that can detect this. 

1.3.9 Object Mobility 

An object migration vseherne permits an object to move from one machine to another. 
Tluin? are basically two niasons why an object should be migrated: first is to improve 
p(!irormance and tin; second is to improve availability. Migrating a process in a 
convcmtional distributed syst(?m is a difficult task. This is due to the problem in 
moving system dependent information such as values of running clocks, the logical 
communication paths, etc. In a distributed objfjct oriented programming system, 
this is simplified, since an object clearly defines the entiti(?s that must be moved as 
a. single unit. In addition, tin? property of location transi)arency permits a system to 
(hitermine the new location automatically. 
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1.4 An Overview of Some Existing Systems 


1.4.1 Emerald 


lMucral(l[19| is a distributed object based prograimuiug language and run-time system 
devc'lojx'.d at the University of Washington. In Emerald, all entities are objects. Both 
passive obj(!cts and ac-tive objects are supported. Concurrency within an object is 
also supported. A pessimistic synchronisation scheme that uses monitors and an 
immutable obje(;t r<;plication scheme are also implemented. Emerald iises a cache 
scIkuik^ that us(^.s forward location pointers for locating remote objects. It supports 
obj('(d. migration wherein processes executing in the object are stopped, the state of 
t.h(' obj(^ct is sent, to the destination machine, the object is created on that machine 
with tlu' state and the proce.sses are resumed. The system docs not take care of 
r('(|U{!st.s that arrive while the object is in transition. In Emerald, a single common 
ad(lr('ss si)ac(; is shared by all objects on a machine. This reduces the cost of creation of 
objc'cts and enables objects to examine and modify each other directly. But, there are 
no hardware protections between objects and hence, an object failure can potentially 
lead 1.0 an (uitire machine failure. Emerald does not support a security scheme and 
it replicates immutable objects only. There is no notion ol classes and inheiitance. 
Only (•all-by-referenc(i is supported. To reduce the overhead that will arise because of 
the r<!mot(i invocations on the objects passed as parameters, the object to be passed is 
moved physically to the called machine for the duration of the call. This mechanism is 
ternu'd as call-by-movc in Emerald. The distributed programs developed in a system 
and a, language like Emerald typically oiierate in a separate environment and it is 
more dillicult to integrate them into existing systems. 


1.4.2 Sloop 

Sloop[17| is a paralhd language and an environment employing object oriented model. 
It supjiorts the notion of classes and inheritance. Sloop employs passive object model. 
It hides the underlying multiprocessor environment with the abstraction of virtual 
ohjrct. .space which amsists of a colhuttion of coordinating objects called douiaim. 
ISach domain providcis operations for creating objects, getting object location from 
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name, making a group of objects reside on a specified processor and for replicating 
an oI)jec(,. Objects interact with domain objects as tliey interact with other normal 
()bj(;c(,s. 

Object types have a feature called exclusion level which can be either re-entrant 
or iv, divisible to indicate whether object’s operations can proceed concurrently or 
not. Even in re-cuitrant objects, true coiunirrency is not provided. Once invoked, 
a re-entrant operation will run until it either surrenders control or invokes another 
ojjeration. Moreover, programmer should ensure that the re-entrant operations leave 
1,h(! object in a consist(!nt s<,at(! befor(i surrendering control or invoking some other 
operation. 

For synchronisation, a construct called await is provided. Any operation executing 
the statement await P will wait till the condition P becomes true. Sloop does dynamic 
load Ijalancing by monitoring the load and migrating objects. It uses coroutines rather 
than processes for operation execution. It also provides real-time support. The user 
can S])ecify an object, an operation and a time interval. The system will periodically 
invoke the operation of the object. Both implicit and explicit object scheduling are 
supported. Object migration can be done both by the user and the system. Naming 
scheme is based on capabilities. There is no security sclu'.me and the system does not 
support atomic actions and reliability. 

1.4.3 Argus 

Argus[lG] is a system and a language developed at Massachusetts Institute of Tech- 
nology. It provides support for fault-tolerant distributed programming. It supports 
dynamic variation of the active object model and it minimises the overhead in process 
cre.ation and chistruction by maintaining a pool of idle processes. In Argus, objects 
a.r(i ca.ll(Kl as guardimis and there is a section called recover in a guardian that is 
(!X(Hmt(Hl whenever tin; objcr.t is recovered after a crash. Argus supports transactions 
and a p('ssimistic sdnuiu' that uses n'ad/wriU’ locks for syn<-hronisation. A guardian 
manag(M‘ is (ix(H:iit(Kl on (iai^h machine to create new guardians on it, to det(!Ct failures 
and to recover guardians after a failure. Security and obj<'{'t replication are not sup- 
port(!d. Location of the guardian is encotled within its name and hence guardians are 
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iiiunobilc. Clients use an invoeation probe scheme to (l(h,(H;t failures and servers use 
a status report scheme to <letoct invocation failures. To support recovery, a commit 
log is maintained in secondary storage. Argus docs not free the programmer from 
worrying about the details of concurrency. The programmer must think about dead- 
locks and starvation and implement the code to avoid them when possible. Moreover, 
there is no notion of classes and inheritaiu'C in Argus. 


1.4.4 Eden 

hd(!n[l] is a system and a programming language developed to build distributed ob- 
ject based applications. Eden supports the static variation of the active object model. 
Each Eden object or Eject has a long-term state that contains the persistent informa- 
tion, a short-term state that contains the volatile information and a code segment that 
contains the opcirations. Each Eject has a dispatcher process for accepting requests 
and assigning to idle server processes, one or more server processes and some mainte- 
nanc(i processes. Eden’s kernel itself is implemented as a Unix process and it supports 
primitives for asynchronous message passing. Eject creation and checkpointing. Even 
though portability of the system is enhanced by having the Eden kernel as a process 
th(!r(! is a high ovcu he.ad of communication between Ejects and the Eden kernel. Eden 
does not support automatic garbage collection and atomic actions. Eden has a pre- 
I)rf)cessor which generates stubs for Eden object types and relieves the programmer 
from worrying about the communic;ation primitives. The generated stubs provide 
synchronous communication based on the asynchronous communication provided by 
tlu! kernel. A pessimistic syiu^hronisation scheme that uses monitors, a capability 
security scheme and a recovery scheme that uses checkpoints are also provided. In 
Eden, one Eject can have only one capability. This prevents grouping together of 
l.wo Ej(u:ts into one without also changing their interfaces. Checkpointing in Eden 
rej)lac(!S an entire Eject state rather than selectively updating even for very small 
changes in the state. Object replication is also supported. It supports cache scheme 
for loc.ating objects. Timeout scheme is used by clients to detect invocation failures. 
Implicit object scheduling is also supported. 
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1.4.5 Aeolus 


A(’()lus[3] is a prograimriing language for iinplemcnting distributed fault-tolerant pro- 
grams on the Clouds[8] distributed operating system. Both Aeolus and Clouds were 
(h'voloixul at Georgia Institute of Technology. Aeolus supports only passive objects. 
An object consists of a number of segments: a code segment, one or more data seg- 
uKuits for i)ersistent (lata and a number of heap segments for volatile data. Code 
segments can be shared between multiple objects. When an invocation is made on an 
objcict, the associated process enters the object through one of the entry points in the 
code .segment, cixecutes the corresponding operation and then leaves the object. A 
programmer can specify whether automatic recovery is needed or custom recovery is 
needed. In the former case, entire state of an object will be checkpointed and in the 
latter case, only those parts of the object that have been indicated by the programmer 
will be checkpointed. The programmer can also specify whether automatic synchro- 
nisation which is of pessimistic nature is needed. The programmer can also achieve 
synchronisation by using locks (ixplicitly. The drawback of this scheme is that serializ- 
ability of actions can not be enforced by the system. Even though, Aeolus gives more 
Ik^xibility for optimising recovery and synchronisation, the many features thus intro- 
duced make it a comi)lex language. A capability scheme is supported for security. It 
also supports a recovery scheme and obj(ict replication. When an invocation is made 
on a remote object, a local communication manager broadcasts a search and invoke 
rcHiuest containing tlie capability of the object, name of tlu' operation and the param- 
eters. Each communication manager receiving this request, does an internal search 
for the object. If found, the communication manager accepts the request, creates a 
worker i)rocess to execute on behalf of the client. When the operation terminates, a 
reply is sent back to the communication manager on the client machine. Clients use 
a probing sclu'.me and servens use a tim(a)ut .scheme for ch'tecting invocation failures. 
Obj(>ct scheduling is also supported. Aeolus makes direct use of Clouds primitives 
and hence it is veuy dillicult to port the programs develoixxl in Aeolus to bo run on 
other op(U'ating systems. 
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1.4.6 CORBA 


Heterogeneity jircsent in large networks like the Internet and corporate intranets 
enables one to use the best combination of software and hardware for each part 
of the enterprise. But the components developed in different parts cannot be in- 
tegrated together unless there are right standards for interoperability and porta- 
bility. In view of this problem, Object Management Group(OMG) was formed to 
develop, adapt and promote standards for the development and deployment of ap- 
plications in distributed heterogeneous environment. Coinnion Object Request Bro- 
ker Architecture(CORBA)[27] is one of the specifications proposed by OMG for the 
d('.velo])ment of interoperable and portable software. There are many commercial 
implementations of CORBA such as Orbix[2]. 

CORBA sui)ports both passive objects and active objects. Objects are named 
using an approach similar to capability scluiine. The capability is called tis object ref- 
('nnice in CORBA. Security and naming service are incorporated as CORBA services 
which can be used by clients. Both synchronous calling mechanism and asynchronous 
calling mechanism are supported. CORBA hides the location of the object, the exe- 
cution state of the object and the language in which the object was created from the 
clicuit. So, a (client written in oiK^ language can invoke methods of an object written in 
another language possibly executing on another machine running a different operat- 
ing system. A locking mechanism is provided by the concurrency service of CORBA 
for synchronising concurrent callers of an object. Atomic actions and recovery are 
supportcHl by the transaction service of CORBA. CORBA has no client operations for 
objc^ct cn^ation. Objects are createrl by invoking methods on built-in objects called 
factory objects. CORBA does not allow objects to be passed by value and it does 
not vei)licate objects also. 


1.5 Scope of the Present Work 

All th(> above systems either support each feature of a distributed object oriented 
system in a rigid manner or do not support it at all. CORBA does not allow the 
cli(Mits to cr(uU,(> obj(K;ts in a transparent manner, i.e., the client has to invoke methods 
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of some factory objects to create other objects. Emerald, Argus and Eden do not 
support classes and inheritance. Emerald, Aeolus and Argus are languages developed 
especially for specific systems and hence programs written using those languages are 
not portable. Emerald, Sloop and Argus do not support a security scheme. CORBA 
and Eden provide a security scheme that is inflexible. Argus and Eden support active 
objects only whereas Sloop and Aeolus support passive objects only. Argus and 
CORBA do not replicate objects. Atomic actions and reliability are not supported 
in Sloop. Object migration is not supported in Argus. 

The scope of this work is to design and implement a distributed object oriented 
programming environment (VASTU) that would enable programmers to easily write 
distributed object oriented applications. VASTU supports classes and inheritance. 
It supports both active objects and passive objects. Object creation, usage and 
destruction are done in a transparent manner in the sense that they are similar for 
both passive objects and active objects. The security scheme is based on capability 
and control procedure. This scheme is highly flexible. Naming scheme is based on 
capability and name server. Internal concurrency within an object is also supported 
optionally. Clients use a timeout scheme to detect invocation failures. Both implicit 
and explicit scheduling schemes are supported. VASTU makes use of an existing 
object oriented language (C++) and hence the programs written using VASTU are 
highly portable. It currently does not support object migration and replication, 
atomic actions etc. 


1.6 Organization of the Report 

The rest of the report is organized as follows. The design of VASTU is presented in 
Chapter 2. In Chapter 3 we describe its implementation. In Chapter 4 we describe 
how to develop distributed object oriented programs in VASTU with an example. A 
summary of the work done is presented in Chapter 5. 



Chapter 2 


System Design 


In this chapter, we describe the design of VASTU. First, we present the design goals. 
Th('n, we describe the possible design approaches and choose one that best meets our 
goals. We then proceed to descril)e the nature of objects in VASTU, the way they are 
(U’eated and the way they are named. Finally, we describe how we support internal 
concurrency within objects in VASTU. 


2.1 Design Goals 

Our aim is to creat(; a distributed ol)je(;t orienUHl i)rogramming environmont(VASTU) 
which supports obj<!ct crciation, usage ami destruction in a transparent and secure 
manmu’, and with reasonable performance. The programs developed in such an envi- 
ronimuit should be highly portable. Eventually, VASTU should also support features 
such as persistent objects, replicated objects and object migration. We did not plan 
to sup[)()rt these features in the first version of the syst em that is described here. 
IIow(>v(!r, in order to add supi)oit for such features in tlu' future, the system should 
b(i flexible enough to accommodate the necessary changes. We want VASTU to sup- 
port both the following scenarios — one in which a program creates some objects 
on remote machines, iises them and then destroys them; and the other in which an 
object, acts as a. s(u v(u- and accepts rcupu'sts from any (•lient program, not only the 
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OIK! that created it. The first situation would occur when a program wishes to dis- 
tribute its computations among several processors on the network. Support for the 
latter scenario would enable the use of the system for the development of the usual 
client-server kind of a[)plications. 

2.2 Programming Language Considerations 

A distrilnited object oriented iirogram, in general, consists of several objects, which 
may (!xist at several dillbrcnt machines. Thus when an object invokes a method of 
another object, the target object may be either local or remote. Method invocation 
on a remote object needs to be handled differently than method invocation on a 
local object. In the former case, wc have to send a request message to the process 
imiilementing the remote object. But in the interest of transparency, the programmer 
should be able to make the two kinds of invocations in the same manner. Thus, the 
nm-time system should know which objects are remote and which are local. At the 
time of creation of an object, the run-time system needs to know whether the object 
should be creati'd locally or remotely. Since the system cannot, in general, make 
this decision intelligently, the programmer needs to specify this in some way. Thus, it 
would He(!m that for supporting distributed object oriented programming either a new 
language is required or extensions need to be made to some existing object oriented 
huigunge. /'yVnc'/aW[19], Sloop[l7], yl 7 y/«,s[l()j, and yl(;n/n.s[3] are e.xamples of object 
oriented languages explicitly designed for supporting distributed programming. 

However, another way to meet the requirements outlined above is to not use a new 
language or extend an existing one but to use automatic code generation. Similar 
kind of problems are also encountered in providing support for distributed program- 
ming using IIBC. In the case of H,PC also, we have local procedures and remote 
procedures and calling a remote procedure has to handled differently than calling a 
local procedure. But, to a programmer, both should appear the same. The way this 
probl(!m is solved in most RPC systems is as follows. The programmer specifies the 
(l(!clara.(,ion of remote procedures in a separate spec.ification language. The compiler 
for this languagi! g('n(!rates (!li('nt and servi'r “stub” procedures in a native language 
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lik(^ Cl. The prograiniiier cxjtnpiles the remote procedures along with the server stub 
in a sc^paratc binary executable file and executes it on a remote machine. The client 
stub j)rocedures are linked with the client program. Whenever the client calls a re- 
mote; procedure, it is the corresponding stub i)rocedure that actually gets called. This 
stub procedure packs parameters into a message, sends it to the server and waits for 
a reply. Upon getting this message, the server stub sees what procedure has to be 
called, extract parameters, calls the required procedure and returns the results to the 
client in a message. The client stub procedure returns the results that it gets from 
the s(;rv(;r to tin; caller. 

This approach is advantageous because there is no need for the users to learn a new 
language for developing distributed programs and the implementation of the approach 
is much easier. The specification language is usually syntactically very similar to the 
native language supported by the system. CORBA^l] follows a similar approach to 
support distribut(;d object orient(;d programming. We also follow the same technique 
and define a separate language for specifying the classes whose remote objects will be 
used in a program. The compiler for this language generates a “client-proxy” class 
and server side code for dispatching requests etc. We use C-T- 1- as the native language 
in which the code is generated and in which the programmer is required to program, 
d’lu; programmer comi)il(;s i.he server code into a separate l)inary executable file. He 
uses the client-proxy class for creating remote objects in his program. Whenever he 
creatt's an obj(;ct of tin; i)roxy <;lass, the <;onstructor for the proxy class (ueates the 
r(;al r(;mote object by executing the corresponding server using a mechanism that will 
be described later. Later, when the client invokes a method on the remote object, 
the m(;thod of the proxy object gets called. It packs parameters into a message and 
sends it to the remote object. Upon receiving this message, the generated code for 
the r(;inote object determines what method has been invoked, extracts parameters 
from the message, invokes the required method and returns the results. 
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2.3 Nature of Objects 

Structure of objects in a distributed object oriented system influences its overall 
design. An object oriented program typically consists of several objects of widely 
varying granularities. The granularity of an object is determined by its size and the 
amount of computation it does. On one end, we have coarse-grain objects which have 
larg(! size, and do a lot of computation. On the other end, we have J’me-gram objects 
which have small size and do a little computation. The time taken for execution by 
a. iiKithod of a. coarse-grain ol)j(!ct is v<ny liigli wluui compared with the overhead 
time in invoking that method. But, in the case of a line-grain object, the overhead 
in method invocation is higher. An example for a coarse-grain object would be a 
da(.a,t)ase object and an example for a line-grain object would be a complex number 
object. 

Most of the existing operating systems do not support object abstraction at the 
opcu at.iug system level. Therefore, we have to implement objects as processes which 
are sui)ported by most operating systems. Thus, all the objects of a program have 
to be implemented using a set of processes. A process in this set can contain either 
OIK! object or a collection of objects. If both the caller object and the called object 
belong to the same process, the mechanism of the call can be the same as in a usual 
seciuential object oriented language and the overhead in calling would be relatively 
less. If the two objects are in different processes, the call would have a much higher 
ov(u h(uwl because messages have to be exchanged between these processes for passing 
parani(U.ers and returning results. Therefore, in our design, only coarse-grain objects 
whose? method execiition time is higher than the calling overhead are implemented as 
s(?parate processes. Fine-grain objects can be contained within a coarse-grain object 
as jjart of the coarse-grain object’s state. In this case, thciir methods can be invoked 
IVom within the containing coarse-grain object only. A coarse-grain object which is 
implemented as a separate process is called an active object. Of course not every 
(•oars('-grain object in a program ne('d be made an active' object. 

If an object invokes the method of another object that resides in a different process 
(which may reside on the same machine or on a different machine), it has to send a 
message containing the parameters of the method and information about the method 
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inv()k(Ml to the called object. Upon receiving the message, the called object needs to 
se(\ what method is being called, extract parameters from the message, invoke the 
required method and return the result in the form of a message. In our design, each 
active object has a main method that does this job. As will be discussed later, this 
nuithod is usually automatically generated. Usually, this method calls a function that 
executes in an infinite loop, waiting for requests and disjjatching them. However, the 
programmer can modify this default behaviour of the generated main method. For 
example, it can be modified to create another thread that does some other activities 
in th(! l)ackgrotm<l. The original thix^ad (;an proceed to wait for requests and dispatch 
them as usual. For example, in the case of a printer manager object that controls the 
job (lueue of a printer, scheduling the job queue can be the background activity. 


2.4 Active Class Description Language 

As alrea.<ly discuissed that we use a separate language for describing the active classes, 
i.e., those classes whose objects will be active. This language is called Active class De- 
scription Language (ADL). We have implemented an ADL compiler which when given 
the declaration of an active class generates a client proxy class, external Data Rep- 
resentation (XDR) routines, server class and server code. XDR[25] is a standard for 
representation of data exchanged between two communicating entities on two differ- 
(iiit iria, chines, t,o take care (jf the architoctui al differeiKU's between the two machines. 
XDR routines are needed to convert data to and from the XDR format. 

The user can use the client proxy class for creating objects of the active class in his 
program. The creation, usage and destruction of active objects and passive objects 
are done in the same way. It is the generated proxy class which hides the process 
cr(;atioi), n'.moU! method invocations and process destruction from the user. When 
an object of the client proxy class is created, it creates a process implementing the 
corresponding active object using the mechanism described in the next section and 
get.s a lumdle for the active object. This handle acts as a capability for the active 
olrject. Later, when a method of the pro.xy object is invoked, the method code which 
is gc.nerated l)y th(i ADL compiler packs the arguments of the method, the handle 


21 



and inlonnation about tho inotliod iuvokod into a mossago. Tlu^ Suii-RPC protocol 
nnissagc Ibrinat is used for this message. It then sends this message to the process 
implementing the active object and returns the result that it gets to the caller. 

Tlui ADL compiler uses the rpegen program [23] to generate XDR functions for 
l)acking and unpacking arguments into messages. Parameters can be any type that 
is supported by rpegen. These include base types such as integers, characters etc., 
arrays, structures etc., of arbitrary types. In addition, leferences to active objects 
can also be passed. This is done by sending the handle for the active object in the 
nuissage. Since objects that are not active; do not have n(;twork wide handles these 
cannot be passed as parameters of methods. 

For the server v(;rsion of the active cUuss, the ADL compiler generates an authen- 
ticate. handle method, an authenticaie.r-equest method, a dispatch method and a main 
method. The authe7dicate.handle method and the authenticate.request method act 
as the control procedures for the object. The dispatch method accepts and services 
method invocation requests. As described earlier, the main method initializes the 
object and calls a function which executes an infinite loop, waiting for requests. This 
fuiudiion uses tho dispatch •method to dispatch the incoming requests. The program- 
mer can use his own versions of these methods if he chooses not to use the ones 
generat(;d by the ADL compiler. 


2.5 Active Object Creation 

A client proxy obj(;ct can not create a proce.s.s imi)lementing the corresponding active 
object on a remote machine by itself. An object server is used to solve this problem. 
An obj(;c.t server runs on every machine in the system and is responsible for creation 
of active objects on that machine. It maintains a repositoi'y of binary executables 
corresponding to active classes. The user compiles the server side code generated for 
t.he active class into a separate binary executable file and submits it to this repository. 

Wlu'iiever a client proxy object is created, it sends a request message containing 
I, In; nann; of the active; class to the object server on an appropriate machine for creating 
an active object of that class. Upon receiving the request message, the object server 



oxecnitos the prograni corresponding to the specified class and returns a handle to the 
])roxy object. 


2.6 Naming of Objects 

As m'. saw in the last section, an object that creates an active object gets back a 
haiulh^ for the active object. The object uses the handle for method invocations 
on tli(i active object. But, in some cases, the creator of an active object and its 
us(!r may be two dilferent entities. In suc.h a situation, the user does not know the 
handle of the active object whose methods he wants to invoke. A name server can 
be ns(Hl to solve this problem. An active object can register its name and handle 
with a name server optionally. Any object which knows the name of an active object 
can obtain the handle of the active object by contacting the name server with the 
name. A name server runs on each machine in the system and maintains a table of 
<object name,handle> mappings for objects which are present on the local machine. 
It provides services to add a mapping, remove a mapping and get an object’s handle 
given its name. 

Currently we have implemented only a very simple name server that manages the 
nam(^s of objects on the local machine. It implements a flat name space. This is 
sufficient for the first version of the system that is described here. However, the name 
space can be made more comijlex and the name service can be made distributed in 
nature later on. 

2.7 Concurrency within Objects 

VASTU allows active objects to be multi-threaded. Programmers can use POSIX 
thread facilities[9] to creat(i threads. All our library functions are either thread-safe 
or hav(! both thread safe and unsafe versions. The ADL compiler has an optional 
switch. If this switch is used, the generated code creates a new thread for servicing 
(inch incoming nicpuist. It is the programmers responsibility to ensure synchronisation 
l)(itw('('n these threads by using POSIX thread synchronisation facilities such as mutex 
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and c.oiulition variables. Therefore, a programmer can choose either a single thread 
scxinential dispatching scheme or a multi-threaded concurrent dispatching scheme 
whence a new thread is created for each incoming request. Actually, there can be 
ol.Iuu' dispatching schemes in l)etw(;en these two. For exami)lc, a pool of idle threads 
can b(! maintained and one of these threads can be assignefl to each incoming request. 
Any such scheme can be easily implemented by the programmer by modifying the 
g(merated code of the dispatch method. Later, if we find that some such scheme is 
ri(H|uently used, the ADL compiler can be modified so that it can generate code for 
that seluiine also. 
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Chapter 3 


Implementation 


In this chapter, we describe the implementation of VASTU. We first describe the 
Act.ivc Class Description Languagc(ADL), the usage of the ADL compiler and the 
code generated by the compiler. Then, we proceed to describe the structure of the 
handle, the authentication mechanism and the way explicit scheduling of objects is 
supported. Then, we describe the way objects are created, invoked and destroyed and 
(,hc way inheritance is supported. Finally, the implementation of the name server is 
pi<>.s(!n(,ed followed by the description of a tyi)ical execution scenario. The underlying 
syst(nn that we have used for our implementation is a collection of Unix machines 
coniK’ctcKl by a communication network. We have used HPC as the communication 
rncichanism and the; particular H.PC implementation that wo have, used is Sun- RPC 
imphunented on Unix platforms. 


3.1 Active Class Description Language 


All ADL specification file contains the declaration of an active class and the data types 
that it uses. The file is structured into three sections. First section has constructs 
lik(^ #f/c/fiies and #mdudes which need to be pfissed untouched to the output files 
geiiei a.ted. In the second section, the i)rogrammer writes the declaration of data types 
of argiiiiKwits of publicly accessible methods of the active class. 'I'ln' syntax of this 
siH-.tion is exactly same as the XDli[2b\ language of the Sun-RPC. The third section 



c.oiitains the declaration of the active class. The syntax of the class declaration is 
similar to the syntax of the class declaration in C++ with the exception that the 
class (uvnnot have public data nieinbors, static members and friends. The grammar of 
this language is given in Appendix A. 

The ADL compiler is implemented using the Unix compiler-compiler tools lex and 
yacc. When a file containing the specification of an active class is given as input, 
this compiler generates a client-proxy class, server class, main function for the server 
program and XDR routines. The specification of the data structures given in the 
second s(u:tion of tin; input file is passed through the rpcyc7i[2'3] compiler to generate 
the XDR routines. 

Th(i inogrammer compiles his i)rograin along with the client-proxy class and the 
XDR, routines to generate the client program. He compiles the main function of the 
server program along with the server class and XDR routines into a separate binary 
(!x<!cutable file. This is illustrated in Figure 3. 



Server program compilation 


Figure 3: Using the ADL compiler 












The generated client proxy class inherits from a predefined class called active-proxy-rooi 
by default. This class provides the data and functionality common to all client proxy 
(Tissos. The declaration of the active^proxy.root class is shown in Figure 4. 


class active_proxy_root 

protected: 

HANDLE h; 

CLIENT *cl; 
int errno; 
public : 

HANDLE get.handleO ; 
int get_errno(); 

virtual HANDLE restrict (unsigned int bitmask); 

}; 


Figure 4: activc_proxy_root class declaration 

Tlie field h stores the handle of the active object. The member cl is the RPC 
style client handle that is created from the handle h. The (irrno field indicates any 
error that might have occurred in a remote method invocation. After every method 
invocation, the client chocks this field to determine whether an error has occurred 
bcifore actually interpreting the results. The geterr-no method ret'urns the value of 
the errno field. The get-handle method is needed in cases, when a client passes an 
active object to another active object. This is explained later. The restrict method is 
defined as a virtual method and needs to be defined in any proxy class that inherits 
from this class. The need for this method will become clear later. ADL compiler 
gencrat(is this method in the proxy classes generated. 

The g(nierated server class inherits from a predefined class called active-root, by 
default, 'riiis class provides the data and functionality common to all server classes 
geneiat('d. Its declaration is shown in Figure 5. 

The check field is used for authentication purposes to be described later. The 
code field stones the value returned by a name server upon registration. This is 
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class active_root 

{ 

protected: 
int check; 
int code; 
public : 

int authenticate_handle (HANDLE h) ; 

int authenticate_request (HANDLE h.int procno) ; 

HANDLE restrict (unsigned int bitmask); 
virtual void main(char *objnajne,int f d) ; 

virtual void disptach (struct svc_req *rqstp,SVCXPRT *transp, 

int handle_authenticated) ; 

}; 


Figure 5: active_root class declaration 


also explained later. The default authentication service is provided as the authenti- 
aitc.handle method and the authenticate.request method of the active-root class and 
can he used l)y any active object. If an active object wants to use its own authenti- 
cation method, it can override these methods. The restrict method is used to restrict 
the handle. The main method and the dispatch method are declared as virtual meth- 
ods of the active-root class and should be defined in the derived classes. The ADL 
compiler generates these methods for each active class. 

I’lie generat(!d c:lient i)roxy chuss has the same name as the input active class. 
I'wo constructors arc provided in the client proxy class. These two are needed for 
the two scenarios — one in which a proxy object needs to be created for an active 
object that is executing already; and the other in which both a proxy object and 
the corresponding active object need to be created. The first of these constructors 
takes an argument which is a handle. It assigns the handle in its private data h, 
c(mv(u (,s this handle into H.PC styl(^ hajidle and stores it in its private data cl. This 
constructor is used to create a client proxy object for an active object that is already 
executing and whose handle is already known. Usually, handle for an active object 
is obtained either by contacting the name server with the name of the object ut by 
invoking tlie (jc.Lhandlc method of a proxy object of the active object. I’he second of 
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constructors is used to actually create the active object. The constructor takes a 
pointer to a structure describing where the object should be created ^ a parameter, 
riie code for this constructor contacts the object server on the remote machine to 
create the active object and obtains a handle for it. The proxy class has a method 
coi i ('Hp()n(ling (,o (vu'h ol the publicly acc(5ssiblc methods of the input active class with 
the sanui name and argument types. Uj^on invocation, this method forms a request 
nuissage and sends it to the active object. 

The s(!rver class has everything the input active class has in addition to the main 
a,nd tlu^ dispatch, nnithods. The mam method creates the server side RPC transport 
handle;, optionally registers the active object with the name server, returns its handle 
to the object server and calls a library function acceptor to wait for requests. When a 
r(;ciucst message arrives, this function invokes the dispatch method of the active class 
to dispatch the request message. 

3.2 Object Handles 

Ea,ch a(;l.iv(; object has a handle which acts as a capability for it. The structure of 
the handle is shown in Figure C. 

typedef struct handle 

unsigned int hostid; 
long port; 

unsigned int rights; 
int check; 

>HANDLE; 

Figure 6: HANDLE structure 

Th(' field hostid carries the internet address of the machine on which the process 
implementing the active objecd, exe<nites. The field port is the UDP port number 
on which the object waits for re(|uests. The rights field indicates the access rights 
that tin; holder of the handle has on the active object. The check field is used for 
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aiil.liciil.icaUon I)ut•p(),s(^s as (i<wc,ril)(ul laior. Evcm thougli, Mic handle structure is not 
curKiiit.ly location and migration transparent, it is suflicient for the first version of 
tlu! systicun and it simplifies the implementation. Later, this can be easily modified 
(,o support other {(^atures such as object migration etc. 


3.2.1 Authentication 


An ac.t.ive object is implemented as a process which uses RPC for its communication. 
'FIki aut,h(uitication mechanism that it us(^s is much more secure than the default Unix 
autluml.ication sclnunc supported by RPC. The default authentication mechanism 
that active; objects use is bfused on the rights and check fields of the handle. This 
sch(;m(; is based upon the authentication scheme in Amoeba[26] and is described below. 

The authentication information in an object handle consists of a rights field and 
a ch(;ck (ie'.ld. The rights field consists of 32 bits and a T’ in any bit denotes that 
the; hold(;r of the handle luis the right to perform some particular operation on the 
obj(;ct. The check fi(;ld is used to prevent unauthorized accesses to the object and to 
ensure; that the holder of a restricted capability for the object (i.e., one in which not 
all bits in the rights field are ‘1’) cannot acquire more rights than it legitimately has. 

Wh(;n an active oliject is created, it generates a random number and stores it in 
a variable. The handle returned to the creator is an owner’s capability for the object 
au<l tlms has Is in all bits of the rights field. The check field of the handle contains 
the generated random number. 

VVh(;n an active object gets a recpiest message with a handle, it checks the rights 
field, if the client has full rights, the object compares the check field in the handle with 
f,h(' iut.<;rnally stor(;d check field. If both of these are cciual, the client is authenticated 
sucec'ssfully. 

A c.li(;nt can restrict the rights of a handle that it has and pass the restricted 
haudh; f,o some other client. To restrict a handle, the client passes the handle to 
the active object along with a bitmask indicating the rights that are needed. Upon 
getting this reciuest, the active object authenticates the handle and creates a new 
Iiandh;. 'Phen, it ANDs the rights field in the handle with the bitmask and stores the 



idsull, in Ui(! riglits lioicl of Uio now haiullo. Finally, it XORs the check field stored 
in(,(una.lly wif.h tlni ne.w rights field and applies a one-way function to this value. It 
stores the r(\sult in the check field of the new handle aiid returns the handle to the 
clknit. 

Wlnni a client seiuls a request with a restricted handle, the object XORs the 
inUnnnlly stored cluick field with the rights field in the handle and applies the same 
on(^-way function to it. The client is authenticated successfully, if the result is equal 
to the (-heck field present in the handle. 

It is obvitnis from tlu; algorithm that a client that tries to add rights that it does 
not hav(! will simply invalidate the handle. The client cannot get the original check 
field from tln^ check field in a restricted handle, because the one-way function that 
is used is computationally hard to invert. The particular one-way function that we 
hav(^ used is a direct implementation of the algorithm proposed by Evans et al [10]. 

d'h(' authenfjeation scheme authenticates the handle only. This is implemented as 
(,h(‘ authenticateJiandle method of the active.root class and hence is available to all 
active classes. Once the handle has been authenticated, one needs to check whether 
the client is sufficiently privileged to invoke the requested method of the object. For 
this purpose, the bit corresponding to the requested method in the rights field of the 
handle has to be checked. Programmers are free to assign any bits to any methods. 
However, by default, the least significant bit of the rights field is interpreted as spec- 
ifying tlm right for destroying the active object. The auihe.nticate.request method of 
the active.root class takes a handle and a procedure number as arguments and deter- 
mines whether the client has the right to invoke the destructor. Note that this can be 
implemented in the active.root class since the destructor method is always assigned 
tlui number 1. The programmer can assign meanings to more bits of the rights field by 
()v<!i riding tin; avMwvM(:(dr..r<'(iur.st. imdluxl of the acUve.^root class. While doing this, 
it must b(^ ensured that dificrent classes in an inheritance hierarchy assign meanings 
to diflenmt sets of bits of the rights field. 'Hie axdhenticaleJiandlv. method can also 
b(^ ov(!rriddcn if one wishes to use some other authentication scheme. However, we 
expect that while the authenticate^request method will be quite frequently overridden, 
l,h(' autherdicateJiandle method will be overridden very rarely. 





1 lit! lian(ll(! r(!sl,ri(;tiou facilil,y is implemented by the restrict method of the ac- 
tivc.^root class. 1 h(^ restrict method of the proxy object invokes this method to restrict 
the handle. 


3.3 Object Creation 

Sc;h('dnliug an a(;tive object at the time of creation is an important issue. By schedul- 
ing, wc tnean tlu' s(ile(;tion of tlni machine on whic^h the new object will be created. 
I'jXi)licit Hcheduling means that the machine on which the new object will be created 
is si)<K;ifi(xl by the programmer and implicit scheduling means that the system de- 
termiiK^H the machine on which the new object is created. VASTU supports both 
implicit scheduling and explicit scheduling of objects. Currently, implicit scheduling 
means creating the object on the same machine as that of its creator. We support 
explicit scheduling of objects by allowing the programmer to specify a list of machines 
to be tried for objoed. creation. As, we already discussed, the generated client proxy 
class has a constructor that takes an argument which is a pointer to a structure of 
type OB.LCR-PAliAMS. This structure is shown in Figure 7. 


typedef struct object_creation_pararas 

char ^machines LMAXMACHNAME] ; 
int n_machines ; 
char *obj_name; 
char *pathnarae [MAXPATHNAME] ; 

} OBJ_CR_PARAMS ; 


li'igure 7: OBJ_CR_PARAMS structure 

Using this st.ructure, a client can specify a list of inachirKjs on which object creation 
has to be tri(xl out. 'fhe ujmachmes field indicates the number of machines specified 
in j.h(' list. The machines field is an array of machine names. The obj.name field 
specifies a name for the object that should be registered with the name server. If a 
cli(uit do(!S not want to register the active object with the name server, it can give 
a NUliL vahie in this field. The pathname field is an array of pathnames of binary 
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(?x(!( ul.fil)l('s (;<)n(!.si)()tKiiug to the active object on each of tlic machines specified. The 
l)inary «ix<u;ii(,a.ble filci corresponding to an active class may not be submitted in the 
repository maintained by the object server. In this case, the programmer specifies the 
pathnauKi of th(^ binary executable file in the pnthnamrAickl. If the binary executable 
fil(' is submitt<Hi in the repository of an object server, the programmer can give a 
NULL value in the pathname field. In this case, the name of the class represents the 
naiiK^ of t,he binary ex(!cu table; file in the repository. 


A prograinm(;r who chooses to use explicit scheduling, needs to pass a pointer to an 
( )li.L( )H...FAH.AMS structure containing the necessary information to the constructor. 
()Ui<;rwise, h<; passes a NULL pointer to use implicit scheduling. The constructor 
a<;tuaily us<;s the; ohj-create function of our library to do the scheduling. 


An ol)j(;cl. se’rver maintains a repository of binary executable files corresponding 


t,o active; class(;s. .After compiling the; server side code generated for an active class 
into a binary (;xecuta.bl(; file, a programmer can submit it in this repository. Ihe 
obje.e;!. se.rver sui)ports two services. The services are — creation of an active object 
givf;n t.lu; nam(; of the class; and giving load information upon request. The load 
information that is provid(;d currently is the number of active objects present on the 
local machine. The load information is expected to be used for implicit scheduling but 
w(; do not, nac. it curr(;utly. The object s(;rver is implemeuted as an RPC server and it 


cuncntly uses the Unix authentication scheme supported by RPC for authenticating 
(;licnt,s. 'rids aut.h<;ntication <;an lx; (lasily broken as it is based on the user id and 
(jroup id of the clients. However, DES authentication can be used if stricter security 


is required. 

When a program implementing an active object begins execution, its mam func- 
t,ion g(>(,s called. This function creates an object of the active class and invokes the 
main m(;tho<I of tlx; a(;tive obji'ct. 'I'lx; main function and the main method are 
generated by the ADL compiler. The main method creates a handle for the object. 
This handle nee<ls to be returned to the object server that has created the active 
object. Unix pipes are used for this communication. The object server opens a pipe 
before forking the process that implements the active object. It passes the write file 
de.scriptor number of the pipe to this process as a command line argument. The mam 
method writes the handle into the pipe using this file descriptor. The object server 





i(';i(ls l,li(> hjUKlI(> iisiiif* (,h(‘ rend filo closcriptor of t,hc pipo and rot, urns the handle 
to t.ho client. Optionally, the client passes a name for the new object to the object 
Htu vfu'. 1 he object s(U'ver passes thivS name to the active object again as a command 
liiH! argument. If this name is not NULL, the main method registers a restricted 
handl(' an<l tlu; name with the name server. 


As can b(! se(Mi, this in(,(ulace <loes not restrict the creation of active objects via 
only th(5 object server. Active objects can also be created simply by executing the 
corresponding binary executable in the usual manner. Thus “daemon objects” can 
b(^ easily creatt'd at boot time.. 


3.4 Invoking Remote Objects 

A protocol needs to be followed between the proxy object and the corresponding 
a(h,ive obj(H;t. h’or each method invocation, the proxy object forms a request mes- 
sage and s(uids it, to tin; active object. This message contains the parameters of the 
met.hod, the handle of the object, a number indicating the method invoked and the 
nanu' of the class. The need for the class name will become clear soon. Upon getting 
l.his luc.ssage, tin; active object extracts the class name and the handle from the mes- 
Hag<!, autlumticates th(^ handle, determines what method is invoked, authenticates the 
r<x|uest, extracts parameters, invokes the method, forms a reply message containing 
the result and sends it back to the proxy object. The method number is passed in the 
pro(x'dur(‘ numl)or field of the H,PC message. The name of the class, the handle and 
th(! arguments are ])acked in that order into the data portion of the RPC message. 

'I'lie arguiiKUits of the methods of the active object can be of any type supported 
by rpqjCM such as integers, characters, floating point numbers, structures, arrays etc. 
In addi(,ion, active objects can be passed as arguments to methods of active objects. 
This is done by passing the handle for the active object to be passed. Thus active 
oI)j(!cis (tan only be passed by reference. The getJiandlc method of the client proxy 
class is used to obtain the handle of the active object being passed. On the server 
sid(t, a (tlient proxy object for that active object is created using the handle that is 
passetd and a refentnee to the proxy object is actually passed to the method of the 



('all<'<l acl.ivt^ I Ik; ('.onstiucior oI tlu; proxy class with an argument of type 

llANlJLlo is us(;(l to (:r(;atc this proxy object. Passive objects can not be passed by 
rclcrciKV', sinc(; they do not have network wide references such as handles. To support 
passing ()bj(;cts by va,lu(;, the method code of the chxsscs should be made available on 
tlu; calhK; side. This is a dillicult task and hence we do not support passing objects 
by value cmrrently. 

VVhen<;v(;r a recpiest message for method invocation is received, the dispatch method 
of t.he ol)j(;ct is invoked. It unpacks the class name and the handle from the message 
and auth(;nticat(;s tin; handle by invoking the authenticatcJiandle method. If the class 
nam<; is saint; as the name of the active class, it authenticates the request by invoking 
t.ht; authmiicate.ivqucst method, unpacks the arguments from the message based on 
t.ht; prottedure number and invokes the appropriate method. Upon successful execu- 
tion of tilt; m(;thod, it packs the; result into a message and sends it back to the client. 
'File .sc(;nario is mon; complicated in the case of inheritance. This will be described 
in a lat(>r .section. 


3.5 Destroying Active Objects 

In many situations, an active object needs to be destroyed once the proxy object 
coirespomling to it is destroy(;d. Code for destroying active objects is generated by 
d(;ra,tdt. A dc.sl.ruc.ior is a(td(;d to th<; cliimt proxy classes generateeb This destructor 
s(;nds an H,PC me.ssage with procedure number 1 to the active object. When the 
di'ipal.ch method of the .server chuss gets a request message with procedure number 
1, it .sends a reply immediately and calls the exit system call. This results in the 
call of the destructor of the active object automatically. The destructor of the active 
object removes its mapping from the name server. This is shown in Figure 8. A 
programmer may not want to destroy an active object that he has created, even 
if the corresponding proxy object is destroyed. Code for this can be generated by 
sp(;cifying an option to the ADL compiler. 




I'^iguro 8: Dostnictiou of an active object 

3.6 Inheritance 

Inluuitance is a relationship between chusscs where one class(bcise class or super class) 
is the i)arent of another class(clerived class or sub class). Inheritance is a natural way 
f.o model the world. It also provides for code and structural reuse. All methods and 
(lata nunnbers of a super class are available to all of its derived classes. This kind of 
r(ius(^ (’.an occur witihin an application as w(ill as across applications also. Inheritance 
is one of the key features of the object oriented programming paradigm. Hence, we 
need to support inheritance in VASTU also. VASTU allows active classes to inherit 
from other active classes. Passive classes can inherit from passive classes as usual. 
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'I'liiis then* <u(^ l.wo cliuss hHuardiios - one in which ail classes are active; and the 
other in whicth all clasH(!S are passive. Thus we do not support a class hierarch}'’ in 
wlii<T SOUK' classes a.r(! active and others are ])}issive. In our opinion, a programmer 
will not wish to do this, since the nature of passive objects and that of active objects 
ar(^ enl.ir('ly dilferent. Mor(iov(ir, passive objects are created on the client side itself 
wlK’i’c’as only proxy objeed.s of a(‘l,ive objects are created on the client side. If a passive 
class inluuits from an a<’,tivo class, in elfcet it is inheriting from the proxy class of the 
active* class and lunic.e* an object of the passive class includes the state of an object of 
the jjroxy c.lass only, 'riujreifore, supj)orting a mixed inheritance hierarchy is a very 
diflie'ult task. 

do explain the; issiuis involved in supporting inheritance, let us take a simple 
(example*. Oonsieler the class liierarchy shown in Figure 9. 

D 



Figure 9: A simple inheritance hierarchy 

In this (example, th(^ activ(^ class A inherits from two active classes B and C. 
Tlu! activ(> class B in tiiru inluu'its from another active class D. In such a scenario, 
th(i programnxu' is re<iuire(l to writ(i the declarations of these active classes in ADL 
in s(!parat<^ sp(x;ilication lil<;s. l'hes(; files are then passed one by one through the 
ADL compiler. I’lu^ ADL compiler generates a client-proxy class, server class, XDR 
routines and main function for each of the input active classes. Iho programmer 
compih's his program along with the client proxy classes and the XDR routines of 



all a(;tiv(^ classes into a client i)r()gram. The binary executable implementing class A 
clearly luaKls to contain code for all the four classes: A, B, C, and D. Thus to get the 
binary executable that implements objects of class A, the main function generated 
lb I' the class A n(i<Kis to be compiled along with all server classes and XDR routines 
generated. 


3.6.1 Method Dispatching 

As numtioried (‘arlier, the dispatch method gets invoked when a request message is 
i-('C(uved by the active object. The dispatch method has to determine which method 
f.o invoke based on the rcHpiest message that it gets. The client proxy object can send 
a number to indicate this if th(^re is a single class. But, in the presence of inheritance 
where there ar(^ many clasH{?s (jach having its own methods, just a number cannot 
indicate the method to be; invoked. Hence, we use the class name and a number 
indicating the methorl within the class to identify the method to be invoked on the 
active object. 

Consider the example hierarchy shown in Figure 9. The same class hierarchy is 
preserved in the proxy classes as well as the server classes. Thus the generated proxy 
class for A inherits from the proxy classes for B and C and the proxy class for B 
inherits from the. proxy class for D. Similarly on the server side, the server class for 
A inherits from the server classes for B and C and the server class for B inherits 
from the server class for D. Let us assume that the client invokes some method of 
class B on a proxy object of class A. The method code packs the class name (B) , the 
handle, the arguments and the procedure number of the method into a message and 
s(!nds it to the active object. Upon receiving the message, the active object invokes 
the dispatch method of Class A. The dispatch method of class A unpacks the class 
name and the handle from the message and authenticates the handle by invoking the 
authenticate-handle method. Then, it checks whether the class name is the name of 
one of its immediate super classes (B and C) or A itself. Since the class name is B (i.e., 
one of the immediate super classes of A), the dispatch method invokes the dispatch 
method of the class B with the rest of the message. The dispatch method of class B 
also checks whether the class name is the name of one of its immediate super classes 



(I)) or li ilscH. SiiKHi tlic chiss name is B, the dispatch method authenticates the 
rc<iu(’sl, l)y invoking tlu! mdhmtiaitc.rcquest method, unpacks the arguments based 
on tin? procednni numljer, invokes the required method, forms a reply message with 
tin? result and s(?nd.s it back to the client. 

Now, let us assume that the client invokes some method of class D on the same 
proxy object. The method code packs the class name (D), the handle, the arguments 
and (.In? |)ro(?e(lur(? number of the method into a message and sends it to the active 
obj(*(?t. Upon r<?c(?iving the message, the active object invokes the dispatch method 
of (Hass A. 'I’ln? dispat, (?h method of class A unpacks the chxss name and the handle 
from (.In? message and authenticates the handle by invoking the authenticateJiandle 
nnU.lnxl. Since l.he ebuss name is not one of the names of its immediate super classes (B 
and Cl) nor i(,s own name (A), it invokes the dispatch methods of its immediate super 
<?ia.ss(?s one? by om?. If one? of them succeeds in dispatching the request, the dispatch 
method of A n?turns. n(?n(?e, th<? dispal.ch method of class B gets invoked first. Since 
tin? c.lass name (U) is the name of one of its immediate super classes, it invokes the 
dispatch method of D. The (ILspatch method of D dispatches the request as described 
earlier and r<?turns (tonl.rol (,o its caller, the dispatch method of B. It returns control 
1.0 (.he dispatch m(?th()d of A which returns control back to the acceptor which once 
again waits for r(?(mests. 

'rids kind of a recursive dispatching is necessary because while generating code for 
a class, tlu? nanu's of only that class and its immediate super classes are known. In 
tlu? shown (?xami)le, whih? the ADL compiler is generating code for class A, it does not 
know (.hat the class A will also (indirectly) inherit from class D. Thus the generated 
dispatch m(?thod for class A cannot itself dispatch a request that invokes a method 
inlu?rited from D. 


3.7 Name Server 

'I'lu? uanu? serv(?r maintains mappings between object names and handles. It is imple- 
m(?nt,(?{l as an ac.tiv{? VASTU obj(?ct and has public methods to register a mapping, 
d(?r(?gist<?r a mapping and to lookup a name. Thus, it can be used to obtain the 



handle for any public-.ly ac.cossiblo ol)joct. But, a client can contact the name server 
only il it, knows t,h(! handler of the name server. This problem is solved by making 
(.h<* bandk^ of tin; name server well-known. Thus, the name server listens to a fixed 
UI)1* port on ea<'h machine. A library routine called getjiamehandle takes a machine 
iiaine as argument and niturns the handle for the name server on that machine. The 
iiaiiK' s('i v('r overrid('s tlu^ default authmUmteJiandle method by a method that al- 
ways i<iports t.hat, f.h(^ handle was valid. The default auihenticate-request method is 
also ov<>rridd(m by a imtthod that, regardless of the rights field, allows all methods to 
be involu'd exc(!pt i\w (h'structor m(d,hod. Hence, the values that the geLnamehandle 
routiiK' puts in the rights field and check field of the handle are irrelevant. 

The nam<* s<*rv<'r ne(!ds to pr(went a malicious client from deregistering a mapping 
which WHS r<<gist.<*r<Kl by some other (dient. This can be ensured by following a scheme 
similar to the autlu'ntication sclu'me. Wheiu'ver a requc'st for registration arrives, 
the name s<‘rvcr gemuates a random number, stores it along with the mapping and 
r(*turns it to tin* clicuiit. Later, when the client wants to deregister a mapping, it needs 
to provitle this number along with the name of the object. 

Soim* active object might have registered itself with the name server and might 
hav<' t.(>rminated without removing its mapping from the name server. Since such 
invaliti mai>pings present with the name server lead to wasted effort, they should be 
removed from the list of mappings maintained by the name server. The main method 
of tint name .server class creates an additional thread that does this periodically. To 
check f.he validity of a mapping, it invokes the method with procedure number 0 on 
th<^ jurtive obj(K‘,t. Each active object returns a dummy reply message whenever it 
riH-xnwH a m<;tho<l invocation recpicst message with procedure number 0. So, all active 
obj(‘c.t.s which do not respond to this invocation request are considered to be dead 
and tlu'ir mai)pings ar(^ removed from the list. 


3.8 A typical Execution Scenario 

In Mgure 10, a typical execiition s(;enario is shown. A client begins execution, creates a 
proxy obj(!ct and pass(;s a pointer to OBJ-CIU’ARAMS structure to the constructor. 



'I’lid (U)iist,ni(;f,()r cjills obj-crcaic library rouiino which contacts an ol)joct server on the 
niachiiu; specilied in the structure. That object server executes the binary executable 
corresponding to the active class. The main function of the process implementing 
the active object invokes the main method of the active object. This method creates 
an RPC server handle and returns a handle for the object to the object server. The 
object server forwards it to the client. The constructor of the proxy object then 
translates this handle to the RPC style handle by calling a library routine translate. 
In the meanwhile, the main method of the active object registers a restricted version 
of it,s handle along with a name passed to it by the object server with the name server 
and calls the acceptor routine of the library to wait for requests. 

Lat(!r, when tlui client invokes a method of the proxy object, the method code 
packs its class name, the handle and arguments into a message and sends it to the 
active object. The acceptor routine reads it and invokes the dispatch method of the 
obj(ic{,. U, unpacks th(i class name and the handle from the message, authenticates 
th(i handh' by invoking the authcnticaieJiandle method and checks whether the class 
naiiK! is saiiH! fis the name of the active class. Then, it authenticates the request 
by invoking the authcnticate.requcst method, unpacks the arguments based on the 
proc('dure numb(;r present in the message and invokes the method of the active object. 
On sncc('ssful completion of the method, the dispatch method forms a reply message 
containing the result and sends it to the client proxy object’s method. The client 
proxy object’s method unpacks the result from the reply message and returns it to 
tlu^ (-alh'r. Meanwhile, on the server side, the dispatch method of 'the active object 
r('t,urns control to the acceptor routine. The acceptor routine once again waits for 
r(Hiu(;sts. 
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I'''igur(i lU: An oxocution scenario 










Chapter 4 


An Example Application 


In Mu' pn^vious couple of chapters, we (lescriboci the design and implementation of 
V'AS'I'II. An (^xaniplf! will nial<(‘ it clear as how to develop distributed object oriented 
programs in VAH'l'U. 'I’lie example i)rogram is a client-server kind of program, in 
which an active objtud acts as the server. 


4.1 Description of the Example 

'I'he problem that we have taken in this example is the implementation of a print 
s<!rv(!r similar to tin; printer daemon Ipd. The server controls the printer queue of a 
prinl.er. It providers service's for adding an entry into the queue, removing an entry 
from tlu* tpKuie and getting the status of the queue. The server has to continuously 
.scheiduhi the jobs present in the queue one by one on the printer. It is implemented as 
an active; e)bje;e't which luis the printer queue as its state and which provides methods 
(se'i vice's) te) submit a je>b, e;ane;e;l a job and to get the status. The active object does 
the; se:iie;eluling of je)bs as a background activity. Clients which want to access the 
se;rviete'K e)f the i^rint server are presided with the declaration of the client-proxy class 
of the' print s(*rve;r class. Therefore, they create proxy objects for the print server 
e)bje;e;t and <u;e:eKK the scrviceis by inve)king the methods of the proxy object. 



4.2 I lie ADL Specification of the Print server class 


1’h<- AI)l> six'cilication for the print server class is shown in Figure 11. 


#include <stdio.h> 

#define MAXNAMESZ 50 

•/.*/. 

typedef struct Qeleraent *Qptr; 
struct Qelement 
{ 

char filename [MAXNAMESZ] ; 
char owner [MAXNAMESZ] ; 
int size; 
int jobno; 

Qptr next; 

>; 

*/.*/. 

active class printserver 

{ 

private : 

Qptr head; 

Qptr tail; 
public : 

int submitCchar filename [MAXNAMESZ] , char owner [MAXNAMESZ] , int size); 
int canceKint jobno); 

Qptr status 0; 


I*'igur(! 11: ADL specification of the print server class 

'I'lit' printer (lueue is iinpleincnted as a linked list whose nodes contain the infor- 
mation iil)()ut <.h<! jobs. Mach luxh' in the list luis the naux'. of the file to be printed, 
its si/(^, l.he login name of the person who has submitted the job and the job number. 
ICacli job is giv('n a job mnnber after it is successfully submitted into the queue. The 
stat(’ of the print server object has a pointer to the first node of the queue(/iea(i) 
and a })ointer to the last node of the queue(faiO. As shown in Figure 11, the print 
sc'rver class provhh's three methods suh7nit, cancel and status to do the three services 
nx'ntioiKHl earlhu. 
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4.3 Generating Code from the ADL Specification 

'i’wo ()[)<, iolial Hwitchos ran lx; enabled when we generate code using the ADL com- 
pilt't, l-’iiHl. Hwi(.<-h .s|><>ci(ie,s (,ha.|, conrunent dispaU-liing scheme is needed and the 
second switch sp(!ciH(^s that code for destructor should not be generated in the client 
l>it)X,v f’lasK gemuatc'd. A setiuential dispatching scheme is sufficient for the print 
server ol)j(Hi,, simtt; it is meant for explanatory purposes. Therefore, the first switch 
should not be ('nabhui. 'I'lie print server object should not be destroyed once the 
pioxy object that lies cr<!ated is (histroyed. Therefore, the second switch needs to 
be (’iialihxl. llen<'(', tin; ADL specifuaition of the print server class is passed through 
the ADL conipihu' with th<^ second switch(specifying that the destructor should not 
!)<• geiK'iated in l.he proxy class) enable<l. The ADL compiler generates the files — 
liriii.L'icnu'r.cbit.li^ prhilscmv.r.scvv.h^ priidsar'ver.serv.cpp, printserverjmain.cpp and 
pnnisrnnr xdr.c.. 'I’ln^ file priniHevvcr.dnt.h contains the declaration of the client- 
pro.xy <'lass an<i tlie thdinition of its nudhods. The file prmtserver.serv.h contains 
the declaration of tlu' s(‘rver (dass. The definition of the dispatch method and the 
main nml.hod are present in th(^ (ih^ printscrvcr.scn).cpp. The printservcr.main.cpp 
file conlains the cod<^ of the server side main function. The XDR routines are present 
in the file print.Hv.rv('.r xdr.c. 


4.4 Buikling the Print Server from the Generated 
Code 

'I'ln* fleclaration of tluf print sfu'ver class present in the printserverserv.h file is mod- 
ified so that it in<-lnd<'s the (h'claration of a new method called .‘tchcdulc. also. The 
.Hrli.td.ulc method schcflules tln^ job (pmue. It removes the jobs one by one from the 
(pK'ue and simulates printing by waiting for some time duration proportional to the 
Si'/.e of (.he job before profxx'ding with the next job. The definition of the snhm.it 
method, amad nu'thod, method and the schedule method are written in a sep- 
aral.e file prinUl.cpp. The gfuieratful main method code is modified so that it creates 
a, new (.lirfuwl to schtslule the jobs before calling the acceptor library routine to wait 



for rcHiucsts. Tho sdmluk rnothod of the print server has to synchronize with other 
iiK'l.liods of (,li(' print server, Ixrcause it is concurrently accessing the state of the print 
SCI vet ol)j<!ct along with oiui of those iinttliods. A mutual exclusion lock (mutex) of 
type pthread-mutexJ supported by the pthread library is used for this purpose. The 
mutex is initialised in the main method. The modifications done to the main method 
are shown in Figure 12. The newly created thread in the main method actually starts 


#include <pthread.h> 


extern printserver obj ; 

pthread_niutex_t m; 
pthread.t t; 

void *schedule(void *x) 

■{ 

obj . schedule () ; 

} 

void printserver ; :main(char >t=naine,int fd) 


pthread_mutex_init (&m,pthread_mutexattr_def ault) ; 
pthread_create (&t , pthread_attr_def ault , 
(pthread_startroutine_t) schedule, (pthread_addr_t)NULL) ; 
acceptorO ; 

> 


Figure 12; Modification of the generated main method 


with a function called schedxde which directly invokes the schedule method. This is 
due t,o the limitation of the pihread.create function of the pthread library that it needs 
a ['unction as the starting routine of the new thread. 




Aliy uuiUiod of (,hc iiriul, .sorviir cliuss which accesses the state of the object, locks 
(.he mutex that is initialiKccl in the main uiethod before accessing the state. The 
method unlocks the mutex immediately after it has accessed the state. The portion 
ol the code which does this in the schedule method and the subinit method is shown 
in Figure 13. The same is done by the cancel method and the status method also. 


int printserver: : submit (char filename [MAXNAMESZ] , 

char owner [MAXNAMESZ] , int size) 
-C 

/* create a new node and copy the arguments 
into the new node*/ 
pthread_mutex_lock(&m) ; 

/* add the node at the end of the queue*/ 
pthread_mutex_unlock(&m) ; 
return 0; 

} 

void printserver :: schedule 0 

{ 

while(l) 

pthread_mutex_lock(&m) ; 

/* remove the first element from the queue*/ 
pthread_mutex_unlock(&m) ; 

/* simulate printing*/ 

> 

} 


h'igurc 13: Synchronisation between the schedule method and the status method 


Tlie files printserver-7nain.(:pp, priTitscrucr.seTv.cpp, piintsei'vcv-xdr.c and printd.cpp 
a.re compiled into a separate binary executable file printserver. The binary executable 
can be executed directly from the shell or through the object server. Hereafter, any 
other client can access this print server object by obtaining a handle from the name 
server and by creating a proxy object of the print server with that handle. 





Chapter 5 


Conclusion 


In this report, we have described the design and implementation of VASTU, a dis- 
tributed object oriented programming environment. VASTU supports both passive 
objects and active objects. Objects are created, used and destroyed in a transparent 
manner. There is a separate specification language(ADL) in which the programmer 
writes the declaration of an active class. When the ADL specification of an active 
class is given as input, the ADL compiler generates code which the programmer uses 
to transparently access objects. The details of the code that is generated and how 
the programmer uses the code arc explained in the report. 

VASTU uses a naming scheme that is based on capabilities and name server. 
Each active object has a handle that acts as the capability for it. The name server 
is implemented as an active object whose handle is well known. An object server 
runs on every machine in the system and is responsible for creating active objects on 
that machine. VASTU supports a default authentication scheme based on handles 
and control procedures. This scheme is highly flexible and programmers can tailor it 
easily for each active object. 

VASTU supports development of distributed programs using an existing object 
oriented programming language, namely C-l— b. As we saw earlier, VASTU has a 
separate specification language for specifying distributed classes. The language is 
syntactically very similar to C++ and hence there is very little difficulty for pro- 
grammers in using VASTU. 



W(! saw earlier that, in each feature of a clkstributed object oriented programming 
systcun, tluue arc; many alternative schemes that can be supported. VASTU support 
for a basic set of those features currently. But, for each of those features, all alternative 
scluiines are supi)orted in VASTU in a flexible manner. The programmer is free to 
choose the alternatives based on his need and tailor them. This is not the case in 
many existing systems which either support these features in a rigid manner or do 
not support them at all. A comparison of VASTU with some existing systems will 
make this clear. VASTU supports the notion of passive objects and the notion of 
active objects unlike Argus and Eden which support active; objects alone and Sloop 
and Aeolus which sujjport passive objects alone. Unlike CORBA, VASTU supports 
e.reation of objects transparently. Inheritance is supported in VASTU whereas systems 
like Emerald, Argus and Eden do not support it. VASTU has a security scheme that 
is highly flexible unlike the rigid security schemes of CORBA and Eden. The security 
schenu; is based on capabilities and control procedures. Emerald, Sloop and Argus 
do not provide a security scheme at all. VASTU allows the programmer to choose 
between a sequential dispatching scheme and a concurrent dispatching scheme. The 
ADL compiler of tin; system generates code in C++ and the programs written in 
VASTU can run on any machine running the Unix operating system and supporting 
RPC. But, i)rograms written in systems such as Emerald, Aeolus and Argus are not 
portable. 

The system that we have described here is only the first version of VASTU. Cur- 
r(;ntly VASTU do(;s not support features such fus implicit scheduling ofobjects, passing 
objects by value to m(;thods of active objects, distributed naming service and relia- 
bility. But, it is flexible enough so that these features can be easily accommodated 
in future. 
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Appendix A 


Active Class Description Language 
Grammar 


specification: SECTIONl SECTI0N2 sections 

f 

sections : /*No sections*/ 

I ACTIVE CLASS ID inheritance body 


inheritance 

1 INK 

body 

J 

1 body.part body 

body_part 

: visibility dec_list 

visibility 

f 

1 PRIVATE 

1 PUBLIC 


/*No inheritance*/ 


/*No body*/ 


/*No visibility=>private*/ 


I PROTECTED ’ : ’ 



dec.list 


fun_data dec_list_fol 


dec_list_fol 

fun.data 

f un_data_fol 

arg_list_fol 

arg.list 
arg_f ollower 

type 

id 

fun_body 


/*No follower for declaration list*, 

fun.data dec_list_fol 
type ID fun_data_fol 

/*Data member*/ 

arg_list_fol /*Function or method*/ 

’ ) ’ f un_body 
arg_list ’)’ fun.body 

: type id arg.follower 


/*prev arg was last I no argument*/ 

I ' , ’ type id arg_f ollower 


: TYPE 

I VIRTUAL TYPE 
1 ACTIVE TYPE 


/*0rdinary type*/ 
/*Virtual function type*/ 
/*Active class type*/ 


ID 

ID ’ C' NUM ’] ’ 
ID ID 


/*normal identifier*/ 
/*array*/ 

/* array*/ 


I 


) * ) 
f 

,Q> >.J 

FUNBODY 


/*No body. Just a prototype*/ 
/*pure virtual function*/ 
/*Body is present*/ 



